Use MiniMax-M3 GB300 performance image and fix MNNVL workspace by Oseltamivir · Pull Request #1888 · SemiAnalysisAI/InferenceX

Oseltamivir · 2026-06-22T23:54:03Z

What changed

Update the GB300 MiniMax-M3 Dynamo-vLLM master config and all 15 srt-slurm recipes to vllm/vllm-openai:minimax-m3-perf-arm64-13.0.1-7a67223.
Add an ARM-specific minimax-m3-gb300-vllm-fixes.sh setup script that:
- allocates FlashInfer MNNVL workspace for the one-shot all-reduce sizes vLLM selects;
- makes the MiniMax-M3 MSA prefill top-k slice contiguous before CSR construction.
Wire the setup script through srtctl apply --setup-script for GB300 MiniMax-M3 only.
Keep topology, concurrency, KV-cache, CUDA-graph, and benchmark settings unchanged.
Merge current main and append this PR's changelog entry after main's existing history.

Why

The TP8 decoder failed during CUDA graph capture because FlashInfer allocated about 4.3 MB of MNNVL workspace while the selected one-shot problem required about 16.5 MB. force_oneshot_support=True sizes the workspace for the strategy vLLM uses.

Validation

Generated 31 MiniMax-M3 Dynamo-vLLM entries, including all 15 GB300 entries on the performance image.
uv run --with pytest --with pydantic --with pyyaml python -m pytest utils/matrix_logic/ -q (180 passed).
uv run --with pytest --with pydantic --with pyyaml python -m pytest utils/changelog_gate_tests/test_validate_perf_changelog.py -q (20 passed).
Validated both runtime replacements against vLLM commit 7a672233e.
bash -n, ShellCheck, YAML parsing, and the PR-specific git diff --check pass.

The PR remains non-draft with full-sweep-enabled.

Note

Low Risk
Changes are limited to benchmark container pins, Slurm recipe overlays, and runtime vLLM patches inside benchmark jobs—no production serving or auth paths.

Overview
Switches MiniMax-M3 GB300 Dynamo-vLLM benchmarks from vllm/vllm-openai:nightly-aarch64 to the pinned ARM64 image vllm/vllm-openai:minimax-m3-perf-arm64-13.0.1-7a67223 in nvidia-master.yaml and all 15 minimax-m3-gb300-fp8 disagg recipes; topology and other benchmark knobs stay the same.

Adds minimax-m3-gb300-vllm-fixes.sh, a job-time patcher that edits the installed vllm package: it sets force_oneshot_support for MNNVL FlashInfer all-reduce and makes the MiniMax M3 MSA prefill_topk slice .contiguous() before CSR use. launch_gb300-nv.sh now copies that script into srt-slurm and passes --setup-script on srtctl apply for minimaxm3 dynamo-vllm runs (with srtctl apply args refactored into an array, matching the B300 launcher pattern).

Documents the change under minimaxm3-fp8-gb300-dynamo-vllm in perf-changelog.yaml.

^{Reviewed by Cursor Bugbot for commit d567f25. Bugbot is set up for automated code reviews on this repo. Configure here.}

github-actions · 2026-06-22T23:54:11Z

Thanks for the contribution! For vLLM & SGLang, please ensure that your recipes is similar to the official vLLM recipes and/or the SGLang cookbook

If it is not, please create a PR first before we can merge your single node PR into the master branch. Let's ensure that the documentation is first class such that the entire ML community can benefit from your hard work! Thank you

PR authors are responsible for ensuring that after merging, all GitHub Action jobs fully pass. A lot of the time, failures are just flakes and simply re-running the failed jobs will fix it. If re-running failed jobs is attempted, PR authors are responsible for ensuring it passes. See GitHub's docs on re-running failed jobs: https://docs.github.com/en/actions/how-tos/manage-workflow-runs/re-run-workflows-and-jobs#re-running-failed-jobs-in-a-workflow

As a rule of thumb, generally, PR authors should request a review & get a PR approval from the respective companies' CODEOWNERS before requesting a review from core maintainers.

If additional help is needed, PR authors can reach out to core maintainers over Slack.

感谢你的贡献！对于 vLLM 与 SGLang，请确保你的 recipe 与官方 vLLM recipes 和/或 SGLang cookbook 保持一致

如果不一致，请先创建一个 PR，之后我们才能将你的单节点 PR 合并到 master 分支。让我们确保文档保持一流水准，使整个 ML 社区都能从你的辛勤工作中受益！谢谢

PR 作者有责任确保合并后所有 GitHub Action 任务完全通过。 很多时候失败只是偶发抖动（flake），重新运行失败的任务即可解决。如果选择重新运行失败的任务，PR 作者有责任确保其最终通过。参见 GitHub 关于重新运行失败任务的文档：https://docs.github.com/en/actions/how-tos/manage-workflow-runs/re-run-workflows-and-jobs#re-running-failed-jobs-in-a-workflow

一般而言，PR 作者应先向相应公司的 CODEOWNERS 请求审阅并获得 PR 批准，然后再请求核心维护者审阅。

如需更多帮助，PR 作者可通过 Slack 联系核心维护者。

github-actions · 2026-06-22T23:54:11Z